home *** CD-ROM | disk | FTP | other *** search
/ EuroCD 3 / EuroCD 3.iso / Programming / vbcc / machines / amiga68k / doc / alib.doc next >
Encoding:
Text File  |  1998-06-24  |  4.8 KB  |  89 lines
  1. Article 1351 of net.micro.amiga:
  2. Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site well.UUCP
  3. Posting-Version: version B 2.10.2 9/18/84; site 3comvax.UUCP
  4. Path: well!ptsfa!qantel!lll-crg!seismo!harvard!talcott!panda!genrad!decvax!decwrl!glacier!oliveb!3comvax!mykes
  5. From: mykes@3comvax.UUCP (Mike Schwartz)
  6. Newsgroups: net.micro.amiga
  7. Subject: ALib.c MS Dos and AmigaDos object module Librarian
  8. Message-ID: <311@3comvax.UUCP>
  9. Date: 28 Dec 85 22:49:33 GMT
  10. Date-Received: 31 Dec 85 09:50:35 GMT
  11. Distribution: net
  12. Organization: 3Com Corp; Mountain View, CA
  13. Lines: 468
  14.  
  15. *** REPLACE THIS LINE WITH YOUR MESSAGE ***
  16. Here is a simple utility I wrote a while back for the Amiga, which can
  17. save a lot of compilation time.  It is a Lattice and AmigaDos compatible
  18. object module librarian with basic replace/add, delete, and directory
  19. functions.  ALib is like an archive-type tool for those .o files created
  20. by the Lattice 'C' compler.  Smaller program modules can be compiled and
  21. added together into libraries, which can be linked with other object modules.
  22. ALib is totally portable between the IBM PC and Native Amiga environments.
  23.  
  24. Theory of Operation:
  25.    AmigaDos object files have a structure that allows them to be concatonated
  26.    together and still be valid input to the linker (ALink).  ALink reads in
  27.    object modules in two ways, although it may seem like there are two types
  28.    of object modules.  The filenames listed in the from field are considered
  29.    object modules, and ALL THE OBJECT CODE in the module will be included in
  30.    the output (executable) file (Note: This last statement may not be true,
  31.    but for purposes of this librarian, it doesn't matter).  The filenames
  32.    listed after the library= flag on the linker command line represent
  33.    library modules from which the linker will only include the code for
  34.    those objects referenced by the object modules (this appears to be the
  35.    case from the way my disk drives appear to be seeking thousands of times
  36.    through lc.lib and amiga.lib during Alink).
  37.  
  38.    ALib allows you to create both object modules and libraries.  All of the
  39.    modules (input files to ALink) created by ALib have .lib extensions on
  40.    them, but may be used as either object modules or libraries, or as both.
  41.    This allows the programmer the flexibility of including any or all of
  42.    the linker's options while compiling smaller modules and building 
  43.    libraries of functions that can be used in multiple programs.
  44.  
  45.    ALib also creates a .dir file for each .lib file, which contains the
  46.    information necessary to dynamically substitute, add, or remove
  47.    any of the individual modules that make up a library.  This information
  48.    includes the name of the .o files used to build the library, the offset
  49.    into the .lib file where the object module from the .o can be found,
  50.    and the size of the object module.
  51.  
  52.    ALib works "in-place" on a library, which conserves on disk space 
  53.    tremendously.  This limits the size of output .lib files to the
  54.    amount of free memory that ALib has available to it (over 300K on
  55.    my Amiga).  A block of memory is allocated for each object module
  56.    already existing in the library, as well as for the object modules that
  57.    are to be added.  These blocks of memory are exactly large enough to 
  58.    hold the entire .o input file.  Disk access by ALink is extremely
  59.    efficient, with the minimal amount of head seeks, because it reads
  60.    the entire .o file with one Lattice read() call.  The final output
  61.    library is also written in Large chunks of Lattice write() calls.
  62.  
  63.    The Replace module option is actually a delete module and an add
  64.    module operation.  The delete module operation is simply "forgetting"
  65.    about it - freeing up the memory used by the module, and deleting
  66.    the directory entry for the module.  The add module is simply reading
  67.    the new module into memory and adding a directory entry for it.
  68.    When all the new additions or deletions are done, the new library
  69.    is recorded back on disk.  
  70.  
  71. Comments and Ideas:
  72.    I used ALib to make clib.lib, which contains lc.lib, amiga.lib, and
  73.    debug.lib.  I can use Library=clib.lib instead of 
  74.    Library=lc.lib+amiga.lib+debug.lib when ALink-ing Lattice 'C' Programs.
  75.    I use clib.lib all the time, and it works fine.  I think that it even
  76.    saves some seek time to have one big file instead of 3 separate ones.
  77.    ALink seems to do a lot of head seeks to clib.lib on disk, but from
  78.    ramdisk, I imagine ALink might actually run fast???  
  79.  
  80.    I also am building some libraries, which contain some real useful
  81.    subroutines and functions to complement the AmigaDos, Intuition, and
  82.    Rom Kernel functions.  Things like serial port/modem protocols,
  83.    multiple window management, etc.  I hope to use these in more than one
  84.    program.
  85.  
  86. Enjoy!
  87.  
  88. =============================Cut Here=====================================
  89.